Secure elements are small devices comprising a memory, a processor and an operating system for computing treatments. Such secure elements may comprise a plurality of memories of different types, like non-volatile memory and volatile memory. They are called “secure” because they are able to control the access to the data they contain and to authorize or not the use of data by other machines. The secure elements may also provide computation services based on cryptographic components. In general, secure elements have limited computing resources and limited memory resources and they are intended to be connected to a host machine which provides them with electric power. Secure elements may be removable or fixed to a host machine. For example, smart cards are a kind of secure elements.
A secure element may also be implemented as a virtual entity embedded in a tamper proof device. Such a virtual entity is implemented in software and behaves like a hardware secure element.
Secure elements may be accessed by a remote server via a wireless channel, a wired network, like Internet or through a combination of networks. The remote server communicates with a secure element through a communication session established through a point-to-point link.
A point-to-point link is a communication connection established between two entities. This is different from point-to-multipoint or broadcast communication topology in which several receivers receive information transmitted by one transmitter. These two communication architectures belong to distinct technical domains which have their own technical solutions.
Some secure elements that are intended to be used in Telecom domain or Machine-To-Machine (M2M) domain can be able to manage an OTA (Over-The-Air) channel. These secure elements may also be accessed through the HyperText Transfer Protocol, usually called HTTP or HTTPS for the secure mode. Thus, a distant server can remotely manage the content of a secure element like an UICC (Universal Integrated Circuit Card) through a dedicated communication session using a specific protocol. The server may use by example the RAM (Remote Applet Management) mechanism as defined by GlobalPlatform® v 2.2 standard—Amendment B “RAM over HTTP” or the OMA-DM (Open Mobile Alliance—Device Management) protocol as defined by OMA-TS-DM V1.2.1 standard.
A remote server may be in charge of deploying data in a group of secure elements already deployed on the field. For instance, the data to be deployed may be a script of commands, a new application, an upgrade of an application or even an upgrade of the operating system itself. The data to be deployed may also be applicative data like a new configuration setting or secret data.
Some data is suitable for a configuration of a secure element and incompatible with a different configuration of another secure element. A device configuration may depend on the hardware components and/or the embedded software elements. For example, the configuration may be defined by the operating system version, a profile or a specific data installed in the secure element. The server should take care of any inconsistencies between the secure element configuration and the data to send. In addition, the server must communicate with a huge number of secure elements.
The diversity of the configurations of deployed secure elements is increasing dramatically. This trend increases the complexity of the processing that the server needs to perform to deploy correctly data on the existing fleet of secure elements.
There is a need for improving the way to manage the sending of data from a server to a distant secure element.